Problem

One of the most common IPsec issues is that SAs can become out of sync between the peer devices. As a result, an encrypting device will encrypt traffic with SAs that its peer does not know about. These packets are dropped on the peer with this message logged to the syslog:

Sep  2 13:27:57.707: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet
   has invalid spi for destaddr=20.1.1.2, prot=50, spi=0xB761863E(3076621886), 
   srcaddr=10.1.1.1

There are a few things you need to know about what this command does and does not do: First, invalid spi recovery only serves as a recovery mechanism when the SAs are out of sync. It helps recover from this condition, but does not address the root cause of why SAs are out of sync in the first place. In order to better understand the root cause, you need to enable isakmp and ipsec debug on both tunnel end points. If the problem occurs often, then obtain the debugs and try to address the root cause and not just mask the problem. There is a common misconception of what the crypto isakmp invalid-spi-recovery command actually does. Even without this command, Cisco IOS already performs a kind of invalid SPI recovery functionality when it sends a DELETE notify for the SA received to the sending peer if it already has an IKE SA with that peer. Again, this occurs regardless of whether the crypto isakmp invalid-spi-recovery command is turned on or not. With the crypto isakmp invalid-spi-recovery command, it tries to address the condition where a router receives IPsec traffic with invalid SPI and it does not have an IKE SA with that peer. In that case, it will try to establish a new IKE session with the peer and then send a DELETE notify over the newly created IKE SA. However, this command does not work under all crypto configurations. The only configurations that this command will work for are static crypto maps where the peer is explicitly defined and static peers derived from instantiated crypto maps, such as VTI. Here is a summary of commonly used crypto configurations and whether invalid spi recovery works with that configuration or not: Crypto config Invalid-spi-recovery? Static crypto map Yes Dynamic crypto map No P2P GRE with TP Yes mGRE TP that uses w/ static NHRP mapping Yes mGRE TP that uses w/ dynamic NHRP mapping No sVTI Yes EzVPN client N/A crypto isakmp invalid-spi-recovery 2) IKE Keepalives IPSec is a peer-to-peer type of technology; IP reachability between IPSec peers is required for an IPSec session to be established between them. It is possible that IP connectivity may be lost between the peers due to routing problems, peer reloading, or some other situation. In such cases, there is often no way for IKE and IPSec to identify the loss of peer connectivity. The IPSec control plane protocol (IKE) is based on UDP and is, therefore, inherently connectionless; the IKE and IPSec security associations (SAs) established between the peers can remain until their lifetimes naturally expire. This lack of IPSec session liveliness creates "black holes" where traffic is lost. It is highly desirable to recognize these "black holes" as soon as possible, primarily because the IPSec SAs consume expensive CPU cycles when one side of the session continues to encrypt traffic to its unreachable peer. Also, the lack of failure detection of a peer may prevent the activation of an alternate backup peer. Finally, when reachability to the peer is restored, the peer may have no IKE or IPSec SAs, and the encrypted packets destined to the peer will be dropped by the peer, as it has no valid SA. Hence, the old IKE and IPSec SAs that are still present are really invalid and may preclude the creation of new IPSec SAs. A keepalive mechanism, wherein the peers exchange some type of message to inform each other that they are alive, will help resolve these issues IKE keepalive messages are exchanged periodically by each peer to declare their availability. If three consecutive keepalive messages are unacknowledged, the associated peer is unreachable and the associated SAs should be removed and an IPSec tunnel built to a backup peer if one is present. 3) Dead Peer Detection Dead peer detection (DPD), defined in RFC 3706, is an alternative mechanism that is more scalable than the IKE keepalives in detecting dead IPSec peers. Unlike the keepalive mechanism, DPD does not send periodic messages to check liveliness of a peer. The fundamental premise behind DPD is that DPD is a traffic-based detection method. In other words, DPD specifies that when traffic is occurring between the peers; there is no need to send a keepalive to check for liveliness of the peer, as the IPSec traffic serves as implicit proof of the availability of the peer. crypto isakmp keepalive 60 2 4) Idle Timeout When an IOS router creates an IPSec SA for a peer, it allocates a certain amount of resources to maintain the SA; the SA requires both memory and several managed timers. For idle peers, these resources are wasteful and consume expensive resources. Furthermore, these wasted resources could eventually prevent the router from creating new SAs with other active peers. The solution to this problem is to monitor the SAs for activity, removing idle SAs after a specified period of inactivity. crypto ipsec security-association idle-time 120